Logic analyzers are test equipment that allow inspection of patterns (xe2x80x9clogic statesxe2x80x9d) in logic signals, and detect the occurrence therein of selected events. Early equipment that met this definition operated upon serially transmitted data, such as the bits of characters being sent via RS-232 or register contents being sent over serial busses in a serial micro-processor environment. At present, serial micro-processors are less prevalent than their parallel counterparts, although the serial bit-wise transmission of data continues in many forms (e.g., Internet protocol over an Ethernet), and the term xe2x80x9clogic analyzerxe2x80x9d has generally come to refer to equipment that deals with data occurring in parallel form (as on a sixty-four bit wide bus). The task of serial data analysis has been undertaken by xe2x80x9cserial data analyzersxe2x80x9d and protocol analyzers. Despite this divergence, many of the fundamental concepts remain the same or quite similar (e.g., the notion of triggering), and despite that fact that our examples are presented in the realm of parallel data, it will nonetheless be appreciated that the techniques described below have applicability in the serial environment as well as in the parallel one.
A logic analyzer is an instrument that samples and acquires digital data from a DUT (Device Under Test) or SUT (System Under Test). In some respects its operation resembles its cousin, the digital oscilloscope, in that they both acquire data to produce waveforms. However, the digital xe2x80x98scope can store finely graduated amplitude information, and can condition its trigger on such things as the rate at which a voltage changes. The timing analyzer deals only in highs and lows (excursions about a defined threshold), and only triggers in response to patterns in the data. Modem logic analyzers can be operated either in a timing mode (where samples are acquired at regular intervals, like an oscilloscope) or in a state mode (where the samples are acquired when specific signals occur on the DUT). Logic analyzers are also capable of displaying data as waveforms. This is a standard feature on most commercially available logic analyzers.
Modern logic analyzers have evolved into powerful and sophisticated systems that can monitor hundreds of channels and store tens of millions of states, collectively called a trace, which is stored in a trace memory. However, such a wealth of data is valuable only (1) there is some assurance that the event(s) of interest is indeed among the data; and (2) if the event(s) of interest are not obscured by the sheer number of other routine or uninteresting events that might also be recorded in the trace memory. While post acquisition analysis of a long trace is always a possibility, there are more satisfactory and efficient solutions to this problem. Storage qualification pertains to ways of initially excluding from storage events that are deemed uninteresting. Storage qualification restricts what events that are placed into memory to those that meet some standing criteria; e.g., data read from a certain address in memory. Being finite, however, the memory may eventually be filled, whereupon it is treated as circular and new data overwrites the oldest data. The notion of triggering, on the other hand, is used to recognize the occurrence of some condition believed to be THE EVENT OF INTEREST, and subsequently terminate (immediately or eventually) the data acquisition phase of the measurement (lest the event of interest be overwritten by subsequently acquired data). The stored data of the trace may be likened to a list, and if the trigger event were used in such a way that it occurs at the middle of the completed trace list, then subsequent examination of the trace list would reveal events that led up to the trigger event, as well as those that happened afterwards. It is customary to be able to specify where in the trace list the trigger is to appear, and it is prominently identified as such in the list.
Capturing the desired data frequently hinges on being able to specify a sufficiently meaningful trigger condition. That is, the desired trigger condition (the trigger specification) might be a fairly complicated sequence of events, perhaps even involving alternatives. Often that task of trigger specification development is problematic, since, if one knew what was wrong there would likely be no need to specify a trigger in the first place. But given that there is an unknown problem, one is sometimes forced to discover an effective trigger specification by successive refinement, even with the aid of powerful trigger techniques. This has led to the development of many useful triggering schemes, to which logic analyzers owe much of their present utility.
Initially, trigger specifications were described in boolean terms, using signal names associated with factory assigned input channel names belonging to the analyzer itself, rather than using names associated with the system being investigated. In due course logic analyzers changed to allow the user to specify that certain inputs to the analyzer were to be treated as a field identified by a name, usually called a label. Thus, the operator became free to describe events in terms of more meaningful descriptors, such as ADDR (referring to a defined collection of thirty-two inputs representing an address), DATA (another user defined collection of inputs) and READ (a single bit control line). Once these correspondences are established the associated labels may be treated as variables, allowing the formation of relationships such as ADDR =XXXXXXXX6. A trigger specification is an assemblage of labels used as operands in conjunction with various logical operators, such as AND, OR and NOT, possibly including parenthesis, and forming logical expressions with constants (fixed values) and the relations =,  less than  and  greater than . Labels are much easier to work with than, say, logic analyzer channel numbers, since they are descriptive in terms of the system being investigated. Such a textual boolean description of a trigger specification resembles a segment of programming, perhaps similar to C. The HP 1670 series Logic State Analyzers are representative of this textual mode of trigger specification. Handy as it is, however, the textual boolean representation can also sometimes be difficult to create correctly, particularly when elaborate sequences in time are involved. Not all users are comfortable with such a textual description, especially when timing or duration relationships between signals are to be expressed.
In addition, virtually all logic analyzers can display their acquired results not merely as columnar list of symbols, but also as a waveform diagram. Consider the following situation. A trace has been obtained and upon inspection, the data therein reveals, right there in the trace, the existence of some event (some combination and or sequence of signal conditions) that would be a more productive trigger specification than the one that was just used. At this point the operator of the analyzer is thinking: xe2x80x9cAha! I should trigger on that.xe2x80x9d What he or she then wants to do is change the trigger specification accordingly and perform the measurement again, the better to get an informative description of the event of interest.
All the information needed to extract the desired now trigger specification is present in a display of the trace. But to alter the existing trigger specification or create a new one, it will generally be necessary to leave the screen (or screens) displaying the waveforms of interest and enter ones specific to trigger specification. So the new trigger information of interest is now some distance removed, and now longer visible. Furthermore, it will be necessary to convert this graphical display of a waveform (or segments thereof) into some other format used to specify trigger conditions, such as a textual description involving binary relationships. Many users find converting from a waveform representation to a conventional textual one to be an aggravating and error prone task, perhaps even difficult. These circumstance increase the inconvenience and the possibility of error during the creation of the new trigger specification. It would be desirable if there were an easy and convenient way to utilize the existing waveform display in the definition of the new trigger-specification, and to avoid having to either leave that display or convert its meaning into another format.
By assumption, there is a (are) certain waveform segment(s) of interest in the displayed logic analyzer trace that caused the urge to re-define the trigger specification in the first place. That (those) waveform segment(s) are identified to the logic analyzer by drawing a xe2x80x9crubber bandxe2x80x9d box around them even as they are displayed as part of the trace. The analyzer is instructed to automatically create therefrom, by itself, the desired new trigger specification. It does this by inspecting the captured data corresponding to the contents of the box and creating a description of the associated signal(s) in terms of transitions and steady state conditions. These individual descriptions of activity are then assembled into a trigger specification according to certain rules. More than one box may be drawn. Multiple boxes may be xe2x80x9cstackedxe2x80x9d to include waveform segments separated vertically by intervening waveforms for other signals that are to be excluded. Boxed transitions that appear to line up vertically are treated as though they happened at the same time, even if they in actual fact, did not. Multiple boxes may be displaced horizontally, in which case a sequential ordering of separate events is generally implied. Various screens having auxiliary menus needed to complete the trigger specification are automatically produced as required.